📚 Week 3 · Unit II · Lecture 7
Minimum Viable Product
& Application Deployment

Learning to ship the smallest valuable version of a product fast — and how that product actually gets deployed to real users in a DevOps pipeline.

Dr. Mohsin Furkh DarSchool of Computer Sciences
DateMon, 22 Jun 2026 · 9:00 – 10:00 AM
ProgrammeBTech CSE – 5th / 6th Semester
Today's Agenda
1
Recap — DevOps & Agile
2
What Is a Minimum Viable Product (MVP)?
3
The Build–Measure–Learn Loop
4
MVP vs Prototype vs Full Product
5
Application Deployment — Concepts & Strategies
6
From MVP to Deployment — Putting It Together
Recap
Where We Left Off
✅
Lecture 6: We defined DevOps as culture + automation that bridges the Dev–Ops divide, studied the CAMS framework (Culture, Automation, Measurement, Sharing), the DevOps infinity loop, and how DevOps and Agile complement each other.
🎯
Today: We zoom into the very first practical question every DevOps team faces — "What's the smallest thing we can build, test, and deploy to start learning from real users?" That's the MVP. Then we look at how that product actually reaches users — Application Deployment.
Why MVP Matters in DevOps
  • Smaller releases = smaller, safer deployments
  • Faster feedback loops align with CI/CD philosophy
  • Reduces wasted engineering effort on unwanted features
Why Deployment Matters
  • Code has zero value until it reaches users
  • Deployment is where Dev work meets Ops responsibility
  • Deployment strategy determines risk & rollback speed
Definition
What Is a Minimum Viable Product?

A Minimum Viable Product is the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

— Eric Ries, "The Lean Startup" (2011)
🎯
Minimum
The smallest possible feature set — not the smallest possible quality. It still has to actually work.
✔️
Viable
It must solve a real problem well enough that someone is willing to use it, or even pay for it.
📦
Product
It must be a usable, deployable artifact — not a slide deck or a Figma mockup.
💡
Key Insight: MVP isn't about building a "cheap" or "incomplete" product. It's a learning strategy — build just enough to validate (or invalidate) your riskiest assumption about what customers actually want.
Core Concept
The Build–Measure–Learn Loop

MVPs exist inside a continuous feedback cycle from Lean Startup methodology. Each lap through the loop reduces uncertainty about what to build next.

💡 IdeasHypotheses about users
🔨 BuildSmallest testable version
📦 ProductThe MVP itself
📊 MeasureUsage data, analytics
📈 DataReal evidence collected
🧠 LearnValidated learning

The loop repeats: Learnings inform the next set of Ideas, and the cycle continues.

1
Build
Take your riskiest assumption and build the minimum thing needed to test it — could be a landing page, a single feature, or a manual "fake" process behind the scenes (a "Wizard of Oz" MVP).
2
Measure
Deploy it to real users and collect actionable metrics — signups, click-through rate, retention, time-on-task — not vanity metrics like total page views.
3
Learn
Decide: Persevere (keep building on this direction) or Pivot (change strategy based on what the data revealed).
Real-World Examples
Famous MVPs You Already Know
📹
Dropbox
Before building the full sync engine, founder Drew Houston made a simple explainer video demonstrating the concept. Signups validated demand before a single line of sync code was written.
👞
Zappos
Founder manually photographed shoes at local stores and posted them online. When someone ordered, he personally bought the shoes and shipped them — no inventory, no warehouse.
🏠
Airbnb
Founders rented out air mattresses in their own apartment with a simple website, testing whether strangers would pay to stay in someone's home.
🛒
Amazon
Jeff Bezos started by selling only books online — not "everything" — to validate the e-commerce model before expanding category by category.
🔑
Common Thread: Every example here tested the riskiest assumption first, with the least possible engineering investment, before scaling up.
Clarifications
MVP vs Prototype vs Full Product

These three terms are often confused. Each serves a distinct purpose in the product lifecycle.

Dimension Prototype MVP Full Product
Purpose Visualize / test an idea internally Validate demand with real users Serve the full target market
Used By Internal team, designers, investors Early adopters, real customers General public, all customer segments
Functionality Often non-functional (mockups, clickable demos) Functional, but limited feature set Fully functional, feature-complete
Deployed to Production? Rarely Yes Yes, at scale
Goal Communicate a concept Maximum validated learning per unit effort Maximum value & revenue
⚠️
Common Mistake: Treating MVP as a synonym for "low quality" or "buggy." An MVP must still be reliable, deployable, and genuinely usable — it's minimal in scope, not in engineering discipline.
New Topic
What Is Application Deployment?

Application deployment is the process of making a software application available for use — moving code from a development environment to a production environment where real users can access it.

In a DevOps pipeline, deployment is not a single event — it's the final, automated stage of the CI/CD pipeline, and it directly determines how fast (and how safely) an MVP can reach real users.

💻
Development
Code is written and tested locally on a developer's machine — isolated from real user traffic.
🧪
Staging
A near-identical copy of production used for final QA, integration testing, and stakeholder review.
🌐
Production
The live environment serving real users. This is where deployment strategy and risk management matter most.
Strategies
Common Deployment Strategies

How code reaches production matters as much as the code itself. Different strategies trade off speed, risk, and complexity.

🎯
Big Bang / Recreate
Shut down the old version entirely, deploy the new one. Simple, but causes downtime — high risk for any production-critical app.
🔵🟢
Blue-Green Deployment
Run two identical environments ("Blue" = live, "Green" = new). Switch traffic instantly once Green is verified. Instant rollback by switching back.
🐤
Canary Deployment
Release the new version to a small % of users first (e.g. 5%). Gradually increase if no errors appear. Named after the "canary in a coal mine."
🔄
Rolling Deployment
Update instances gradually, one batch at a time, replacing old versions with new ones — no downtime, but rollback is slower than Blue-Green.
📌
For an MVP: Teams often start with simple strategies (Recreate or basic Rolling) since user volume is low, then graduate to Canary or Blue-Green as the product scales and downtime becomes costlier.
Workflow
From Commit to Production — A Deployment Pipeline
📝 CommitPush to Git repo
🔨 CI BuildCompile & package
🧪 Automated TestsUnit / integration
📦 ArtifactContainer image / build
🧭 Staging DeployPre-production check
🚀 Production DeployLive release
📡 MonitorLogs / alerts / rollback
Common Deployment Tools
  • Jenkins / GitHub Actions / GitLab CI — automation servers
  • Docker — containerize the application
  • Kubernetes — orchestrate containers at scale
  • Terraform / Ansible — infrastructure as code
Deployment Safety Nets
  • Automated rollback if health checks fail
  • Feature flags to toggle features without redeploying
  • Smoke tests immediately post-deployment
  • Monitoring & alerting for real-time visibility
Putting It Together
Why MVP Needs Strong Deployment Practices
🔗
The connection: An MVP's entire value depends on getting real user feedback fast. That's only possible if your deployment pipeline lets you ship changes quickly, safely, and frequently — exactly what DevOps practices enable.
⚡
Speed to Market
Automated CI/CD pipelines mean an MVP idea can go from code to live users in hours, not weeks — critical for validating assumptions quickly.
🔁
Fast Iteration
Each "Learn" step in Build-Measure-Learn requires another deployment. Without automated deployment, this loop slows to a crawl.
🛡️
Safe Experimentation
Canary releases and feature flags let teams test MVP features with a subset of real users — without risking the whole user base.
📉
Low Cost of Failure
Fast rollback mechanisms mean a failed MVP experiment can be undone in minutes — encouraging teams to take more learning risks.
🎯 Bottom Line

An MVP is a product strategy; a deployment pipeline is the engineering capability that makes that strategy executable. Lean Startup thinking tells you what to build minimally — DevOps tells you how to ship it reliably, repeatedly, and fast.

Clarifications
Common MVP & Deployment Pitfalls
❌
"MVP means low quality" — False. A buggy, crashing MVP teaches you nothing — users won't engage with something broken. Minimal scope, not minimal craftsmanship.
❌
"We'll deploy manually for the MVP, automate later" — Risky. Manual deployment slows your feedback loop exactly when speed matters most, and increases the chance of human error during early, high-uncertainty releases.
❌
"More features = more validation" — False. Each added feature increases build time and dilutes the specific hypothesis you're trying to test. Validate one assumption at a time.
✅
Good Practice: Identify your riskiest assumption, build the smallest reliable thing to test it, automate its deployment from day one, and measure real user behavior — not opinions.
Applied Example
Mini Case: Launching a Campus Food-Ordering MVP

Imagine a student team wants to validate demand for a hostel food-ordering app at UPES.

1
Riskiest Assumption
Will students actually pre-order food from mess/canteen via an app instead of walking in?
2
MVP Built
A simple single-page web form (no app, no payment gateway) listing today's menu with an "Order Now" button — order details sent via WhatsApp to canteen staff.
3
Deployed
Hosted on a free-tier cloud server (e.g. Render, Vercel), deployed via a simple CI pipeline so updates can be pushed instantly as feedback comes in.
4
Measured
Track: number of orders/day, repeat usage rate, time saved per student — real behavioral data, not survey opinions.
5
Learn → Decide
If adoption is strong: invest in a real app with payments and push notifications. If weak: pivot the idea or stop — with minimal wasted engineering effort.
Lecture Summary
Key Takeaways

Lecture 7 — Minimum Viable Product & Application Deployment

1
MVP = Validated LearningThe smallest product that tests your riskiest assumption with the least wasted effort — not a "low quality" release.
2
Build–Measure–LearnA continuous loop: build the minimal version, measure real user behavior, learn, then decide to persevere or pivot.
3
MVP ≠ Prototype ≠ Full ProductEach serves a distinct purpose — concept communication, validated learning, and market-scale value respectively.
4
Application DeploymentThe process of moving code from development through staging to production, where real users access it.
5
Deployment StrategiesRecreate, Blue-Green, Canary, and Rolling — each trades off risk, downtime, and rollback speed differently.
6
MVP Needs DevOpsFast, automated, safe deployment pipelines are what make rapid MVP iteration actually possible.
📚 Next Lecture

Lecture 8 (Mon, 22 Jun, 11:00 AM): Continuous Integration (CI) & Continuous Delivery (CD) — We'll dive deep into how CI/CD pipelines automate the build, test, and deployment process we touched on today.

Dr. Mohsin Furkh Dar · School of Computer Sciences · UPES Dehradun

CSDV3016P / CSDV3017 · DevOps Overview · Summer 2026